home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jul 89 / W0004-Control Dim ?S from-Jul89 < prev    next >
Encoding:
Text File  |  1989-07-12  |  5.8 KB  |  157 lines  |  [TEXT/GEOL]
  1. Item    1497777                         3-July-89        10:27
  2.  
  3. From:   D2086                           Efficient Field Svc, C Faith, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. cc:     FRIEDRICH1                      Friedrich, Steve
  8.  
  9. Sub:    Control Dim ?S from CIS, LONG!
  10.  
  11. Here is another message that leaves me perplexed:
  12.  
  13. ********************
  14. I'm having problems with TControl.DimState.
  15.  
  16. I have customized a button, TMyButton, in a TDialogView.  I am trying to alter
  17. the "Dim" method to dim the adornment ring as well as the button itself.  When
  18. the button should be dimmed I call (myButton).DimState.
  19.  
  20. DimState calls DrawContents which eventually calls Draw which then calls Dim.
  21. I have overridden Dim.
  22.  
  23. The problem is that DimState, although called for my customized button, gets
  24. back onto the default chain when it calls DrawContents, so the default
  25. (TControl) Draw is called for the redraw.
  26.  
  27. If I override all three methods: DimState, Draw, and Dim for my customized
  28. button then it works...  provided I write out the entire procedure for
  29. DimState.  In other words I must write:
  30.  
  31.     PROCEDURE TMyButton.DimState (state,
  32.                     redraw: BOOLEAN); OVERRIDE;
  33.     BEGIN
  34.         IF state <> fDimmed THEN
  35.             BEGIN
  36.             fDimmed := state;
  37.             IF redraw THEN
  38.                 DrawContents;
  39.             END;
  40.     END;
  41.  
  42. This is an exact duplicate of TControl.DimState, but if I do it then
  43. DrawContents calls MyButton.Draw and MyButton.Dim.
  44.  
  45. If I just write
  46.  
  47.     PROCEDURE TMyButton.DimState (state,
  48.                     redraw: BOOLEAN); OVERRIDE;
  49.     BEGIN
  50.         INHRITED DimState (state, redraw);
  51.     END;
  52.  
  53. then the default TControl.Draw and TControl.Dim are called.
  54.  
  55. This smells like a bug.  The reference to my instance is being lost.
  56. To: John Jeppson 76174,2007 (X)
  57.  
  58. How frustrating!
  59.  
  60. After forcing TMyButton.DimState to call TMyButton.Draw by completely
  61. duplicating TControl.DimState I now find that I cannot use TMyButton.Dim after
  62. all.
  63.  
  64. Why..  because TCtlMgr.Draw (superClass of TButton) draws controls only by
  65. calling the Control Manager traps.  Its superClass method TControl.Draw is
  66. NEVER called, and only TControl.Draw calls Dim.  So you can override the Dim
  67. method for a customized Button, and that customized Dim method exists, but is
  68. NEVER called by anybody.
  69.  
  70. Is this inheritance???
  71.  
  72. -John Jeppson
  73. ***************
  74. John is doing this in attempt to disable and dim a default button whenever
  75. there is no text in his TEditText item.
  76.  
  77. Another related question that is of a more general nature is:
  78.  
  79. 1) What is the best way to get the button to dim (assume that dim is handled
  80. easily)?  Do you do it from the TEditText doIdle method? DoKeyCommand method?
  81. the TDialogView.PoseModally method?
  82.  
  83. I suggested that John OVERRIDE TEditText.DoMenuCommand and DoKeyCommand and
  84. check to see if the editText has changed to ''.  He replied:
  85. **************
  86. >The trouble with overriding TEditText.DoMenu/KeyCommand is that the
  87. >added capabilities are executed BEFORE rather than after the INHERITED
  88. >action.
  89. >
  90. >    FUNCTION TMyEditText.DoKeyCommand(params);
  91. >    BEGIN
  92. >        DoKeyCommand := INHERITED DoKeyCommand(params);
  93. >
  94. >        DoAddedCapability;
  95. >    END;
  96. >
  97. >The INHERITED feature doesn't happen until this function returns, so
  98. >DoAddedCapability always remains one keypress "behind" the user's
  99. >expectations.
  100.  
  101. and said he OVERRODE the PoseModally method of TDailogView to check the status
  102. of the fEditText field every time.  I replied.
  103.  
  104. Which left me confused! Am I missing something or is he, I replied:
  105. ***********
  106. I am not sure exactly what problem you are having with INHERITED DoKeyCommand.
  107.  
  108. Under your DoKeyCommand method (which should say OVERRIDE at the end) the
  109. INHERITED capability is called before the added capability.  This is probably
  110. what you want, but you say that "The INHERITED feature doesn't happen until
  111. this function returns"  The INHERITED feature happens at whatever point you
  112. call INHERITED.  If you made this statement because this appeared to be the
  113. case then I think there  is some other problem.
  114.  
  115. Your DoKeyCommand function should give DoAddedCapability a look at the finished
  116. product, i.e. the results of the last keypress.  This is what I would assume to
  117. be exactly what you want.
  118.  
  119. In general,
  120.  
  121. 1) You can call INHERITED before DoAddedCapability.
  122.  
  123. 2) You can call INHERITED after DoAddedCapability.
  124.  
  125. 3) You can call INHERITED only If you have not taken care of the function.
  126. This is what TEditText.DoKeyCommand does,  it calls INHERITED only if the
  127. keypress was not in its character set.
  128.  
  129. There are instances when you want to do each of these.
  130.  
  131. The problem I see with your solution is not that it won't work but that it is
  132. too specific.  Your solution works only for modal dialogs.  You would have to
  133. implement an entirely different method for modeless dialogs, (actually windows
  134. really)  they would get events from gApplication PollEvent and I do not
  135. recommend OVERRIDING that method, it would be very messy to do what you want.
  136.  
  137. If you implemented the capability as a function of the TEditText and
  138. TDialogView you could change your dialog to modeless at will.
  139.  
  140. You would have to OVERRIDE TEditText.DoKeyCommand and TEditText.DoMenuCommand.
  141. Also I suggest that a good way to handle the dimming etc. is to have the
  142. TTEditText merely give the TDialogView a chance to look at its contents,
  143. calling a new method TMyDialogView.EditTextChanged(theText,theEditText)
  144. whenever the contents had in fact changed.  The TDialogView.EditTextChanged
  145. method could then do whatever was appropriate based on the change.  This would
  146. also allow you to use these same objects later on do do something slightly
  147. different, and you could use them in modeless dialogs as well.
  148. ************
  149. And that is where it stands right now.  Has anyone done this before?  What did
  150. you do?
  151.  
  152. regards,
  153.  
  154. Curtis Faith
  155.  
  156.  
  157.